Frequently Asked Questions, and Frequently Suggested Ideas.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Before you write to me with suggestions for the next version of Bolo, please read these frequently asked questions, and read the "Bolo.futureplans" file to see if your suggestion is already on the list.
• "With all the problems with network delay in over the Internet, shouldn't I be making an effort to connect into the game via the player closest to me, instead of everyone connecting to the same machine?"
It does not matter. Regardless of the machine you initially establish contact with, Bolo 0.99 automatically "pings" every machine in that game three times to measure the round trip time and other parameters, and then joins into the ring at what it determines to be the optimum point to minimize delay.
• "Bolo is almost unplayable on my slow Mac Plus."
The Macintosh Sound Manager does a lot of work to make those sound effects on older Macs which lack fancy sound hardware. On A Classic 8MHz 68000 Mac, half the CPU time can be spent doing sound, so you can double the performance of Bolo by turning sound off. Alternatively, upgrade to Sound Manager 3.0, which is a lot more efficient, and should be out soon. A beta version has already been given to developers, on the Apple Worldwide Developer Conference CD.
• "What is the Frame Rate menu for?"
If you are running some other program in the background while you play Bolo, setting Bolo to a lower frame rate will allow the background program more CPU time. One example might be when you are running another copy of Bolo in the background, set to Autopilot. The Autopilot will be able to play better if you let it have more CPU time to think with.
• "Why can't different versions of Bolo play in the same game?"
While Bolo is still in development, the comunication protocol is undergoing substantial changes, making different versions completely incompatible. Tell your friends to upgrade to the latest version. It is not as if I am charging any upgrade fee to people who have paid the shareware fee already. If they haven't paid at all, then perhaps seeing the latest version might inspire them to do so :-)
• "When there are several games running, how do I choose which game to join?"
Click on a player in the list who is a member of the game you wish to join.
• "I don't have a network, or any friends with PowerBooks. Can I play by modem?"
I'm told that AppleTalk Remote Access (ARA) works quite well over fast modems.
Bolo does not (yet) support modems directly.
• "So what is the 'Serial Port' option for?"
The serial port option requires use of the harware handshaking lines, so it won't work over modems. Its inclusion is historical -- it was to allow Mac Bolos to communicate with my original BBC Micro Bolo program. If you wire the cables so that the output of each serial port goes to the input of the next, in a ring, then you can connect up to 16 Macs or BBCs together to play Bolo. Now that almost all computers have networking built in, the use of an RS232/422/423 ring is just a historical curiosity.
• "Why is there so little penalty for dying?"
I don't want Bolo to be boring for beginners.
• "So why should I care about getting killed?"
You may be able to do a suicide attack on a pillbox and then pick it up with your next tank when you are playing on your own, but in a crowded game the pillbox will be gone by the time you get back to it.
• "Alliances don't work."
They do. RTFM. Here is how:
1. Select a person whose alliance you would like to join on the "Players" menu and select "Request Alliance" on the "Bolo" menu.
2. If agreeable, that person should then select your name on their "Players" menu and then select "Request Alliance" or "Invite New Allies".
If you are in an alliance, the menu choices are "Invite New Allies" and "Leave Alliance". If you are not, then the menu choices are "Request Alliance" and "Cancel Request".
Take care that you have the correct players selected on the "Players" menu when requesting/inviting.
If you are already in an alliance, you must select “Leave Alliance” first before you can join a new one.
• "Why don't pillboxes shoot each other?"
Can you imagine how dull that would be? Two hostile pillboxes would simply fire at each other at maximum rate and wipe each other out in under a second. All the skill, strategy and tactics would disappear from the game, and the sole decider of who won any confrontation would be whoever had the most pillboxes.
• "Why don't pillboxes shoot at enemy men?"
Pillboxes don't shoot men because they shoot far too well. If they shot at your man, he would be dead, every time.
• "So how am I supposed to stop enemy men putting down hostile pillboxes in the middle of my base?"
Men aren't very bright. They tend to run in straight lines. Design the entrance to your fortress so that a man can't find his way inside.
• "Why can't I steer the man with the keyboard, to guide him around obstacles?"
Because you would then be able to send the man into places which he couldn't reach before. That would invalidate the defense described above, which would mean that there would have to be some other way to prevent hostile men from getting inside a fortress. End result: I do loads of work, the Bolo program gets bigger, you have to learn lots of new keys to operate the new features in the game, and your man still cannot get inside a well defended fortress. What is the benefit?
• "Why did the hostile pillbox I just repaired attack me?"
Because it is hostile. Capture it by picking it up with your tank before you repair it. The only time you might want to repair a hostile pillbox is if it fighting with someone else, and you want to give it some help, but that won't make it loyal to you.
• "When ever I die and get a new tank, I get a 'random' amount of ammo. Why?"
It is not random. The ammo you get is determined by the game type selected by the person who started the game.
• "Why does my tank, when it blows up, sometimes make a huge explosion and sometimes just a tiny one?"
Come on, guess! What do you think influences the size of the explosion? The amount of explosive material you are carrying perhaps?
• "I found a bug. The screen faded out even though I hadn't been killed."
If you are viewing from a pillbox when it is destroyed, then you lose the picture like when your tank is destroyed. Switch to another pillbox, or return to tank view.
• "When I shoot and kill an enemy refuelling base, it doesn't change colour."
That is correct. You can wipe out its defenses by shooting it (and its status indicator on the right of the screen changes to a cross to indicate that it is dead) but it won't change ownership until you drive over it.
• "OK. I drove over the base to capture it, but the status indicator still says it's dead."
That is correct. The refuelling base status will not change from "dead" to "operative" until the base has regained enough strength to defend itself.
• "Who gets to see mines I lay?"
1. All allies see all mines you lay. (This means mines layed while allied, not mines you layed before the alliance was formed, or mines you lay after the alliance is over.)
2. Enemies never see your mines, with one exception: If you drop a mine out of the back of the tank, and there is an enemy close to you, then they see it. Why? For reasons of stability in the game. Before this exception was introduced it was impossible to chase anyone. Even if you have nearly killed them, and they have no shells and no armour, all they had to do was to flee along a road and tap the mine key three times -- bam, bam, bam, you're dead. They can still do this, but instead of instantly killing you it will simply slow down your chase a little while you swerve off the road to avoid the mines.
• "I hate mines. After a hard fight to capture a pillbox, I lose it seconds later by hitting one of the mines that people scatter randomly across the map."
If you are low on armour, and carrying something valuable, BE CAREFUL. Your tank can detect invisible mines up to one map square in front of it, so watch carefully, and drive slowly enough that when you see a mine you can stop before you hit it.
• "Why don't you generate a new random map for each new game?"
There are over a hundred Bolo maps available from various enthusiasts, so you have a wide choice. If you really want random maps, and you think you can write an algorithm which will generate plausible looking interesting maps, then why not write it, and make an application which outputs a random Bolo map file each time you run it? You know what the different terrain types are, you know the map file format, and I've even provided sample C to read and write the files, so the framework is all there for you.
• "Why don't you produce a map editor so that I can create my own maps?"
I was going to, but several other people got impatient and wrote their own. Check out anonymous ftp on Sumex-aim.Stanford.EDU (in "info-mac/game/bolo").
• "Some of the map editors allow you to set the ownership number of bases, but when Bolo saves a map itself, ownership is ignored and all of the bases revert to neutral."
Setting the ownership number for a base falls in the "cute but useless" category. You can make novelty maps where everyone starts with one base and one pillbox, but when you join the game there is no guarantee that you will get the same player number as before, so it is all a bit pointless. 'BGAM' files will be the solution to this problem.
• "Why can't I plant trees?"
Ecology, my friend. If you totally defoliate an area, then it takes 50 years to replant and cultivate a forest again, by which time you probably won't still be playing Bolo (or at least not on your current Macintosh, anyway). If you want to maintain a forest, don't totally destroy it. Farm just a few squares, or farm narrow strips through the forest, leaving the trees on either side to help the farmed area to grow back.
• "Why don't you allow the tank turret to rotate relative to the tank body?"
Many people request this, so that "when driving by a pillbox, you could drive on road and blow it away by shooting to the side." This is precisely the point. To maintain the balance of the game I would then have to make pillboxes more powerful to compensate for your enhanced abilities. The difficulty of shooting a pillbox, or an enemy tank, would be exactly the same, except that you'd have to do more finger ballet on the keyboard to achieve the same results. This would just make the game even harder on novice players (as if it wasn't hard enough already).
• "Why can't the tank reverse?"
Same reason as above. It adds more buttons and adds complication to the game without making it any better. As it is now, if you cleverly catch someone carelessly hanging around on a narrow bridge or beside a lake, you can shoot them and knock them into the water, where they will be almost helpless for you to easily finish off. If they had reverse they could quickly reverse out of the water and escape. In this game, if you are stupid, you pay the penalty. There are no second chances, no smart bombs, and no hyperspace. Watch your back.
• "Why can't I shoot things on land when I am on a boat?"
Boats are for transport, not for fighting. You can however shoot bridges away, and repeated shelling will disintegrate river banks.
• "Why don't you implement line-of-sight-only vision?"
Bolo is a multi-player game. What makes it interesting is the encounters with other players. As it is you can spend far too long searching for the other players in the game, especially when they are hiding in forest, so making it even harder to find other players would not be an improvement.
• "Why don't you add xyz feature?"
One of the main goals in writing Bolo was to try to give it one of the properties that Chess, Othello, and other good board games have -- the "a moment to learn and a lifetime to master" characteristic that gives them lasting interest. The aim is that there are a few simple 'actions' that you can perform in the game, but that they are flexible enough to let you carry out your complex strategies. That's why there is only one kind of tank, one kind of armour, and one kind of bullet. For me to add another major feature, it must add at least as much interest to the game as any of the features that are already there.
• "I turn on 'Background Sound' but there is no music."
Background sound does not mean music, it means Bolo continues to make sounds when you put it in the background to work with some other application. RTBH! (Read the Balloon Help.)
• "Why does the game occasionally seem to freeze for a second or two for no reason?"
When data packets are lost or damaged in the network, it can take the Bolo a few seconds to back-track and get in sync again.
• "I really like Bolo except for the fact that I need to have friends to play it with. Why don't you make a single player version?"
Two answers:
1. If you want a single player game, there are thousands already. Play one of those instead. I'm writing a multi-player game.
2. Run three copies of Bolo in the background, and set them to Computer Control, with the "Aggressive" option set.
If you want to try writing your own Artificial Intelligence routines to drive enemy tanks, sample source code is provided. If it turns out to be popular, we could have a new kind of Bolo Turing Test, where you have to play against various opponents and decide whether they are human or not. (Anyone remember the old 'Core War' tournaments? It would be fun to see Bolo become the battle ground for similar programming competitions).
• "I am going to write a totally awesome network game for the Mac. Please tell me how to do it." (Yes, I really do get this question quite frequently.)
There is no magic spell; no secret to tell. I use simple point-to-point AppleTalk DDP packets. Bolo does not use broadcast DDP packets like most games, because that doesn't work across multiple networks. Bolo does not use ATP, or ADSP, because these offer extra features and reliability that Bolo doesn't need, at the cost of sending extra unnecessary packets on the network. Bolo DOES use NBP to locate other players, but that is of course only at startup time, not during the game itself. The game communication works by having all the machines forward packets from one to the next in turn so that they form a logical ring with packets going all the way round hop-by-hop until they get back to the start. Bolo works equally well with UDP/IP and could work with any other datagram protocol. Point-to-point communications is not a good way to do it, but until there is better support for multicast protocols, there is no good solution to this problem. Seriously, if you want more information, the Cambridge University Computer Science Library has my project report "An Experiment in Real Time Networking" which describes everything in great detail.
• "Can I have source code?"
Sorry, I'm not giving out Bolo source code yet, and perhaps not ever if I decide to sell it commercially. Besides, until I work out the security issues, it would make it too easy for people to compile rogue versions of Bolo with indestructible tanks and unlimited firepower. Is that what you want to meet coming out of the forest on a dark night?
• "What is the "BBC ROM file" 'ROMd' resource? Did you secretly implement a 6502/BBC Micro Emulator just to play this game ;-)"
No, Bolo was originally written for the BBC micro, and then ported to the Mac. The BBC Micro only had a 2MHz 6502 processor and 32K RAM. 20K of that was screen memory, and the operating system consumed another 4K itself, so that only left 8K for Bolo. Even written entirely in 6502 assembly code, Bolo turned out to be just a little too ambitious to fit into 8K, so I had to find some way to get more memory. What I did was to replace the BBC Micro's BASIC ROM chip with a 16K EPROM of my own into which I had programmed all of the graphics character data. Bolo on the Mac still uses exactly the same graphics character data as the original BBC Micro game, which is why the EPROM data is included as a resource. Some day I might decide to improve the graphics on the Mac, but it there are many other higher priorities.
• "I can't ftp from moneygrab.com because we've deliberately crippled our network to 'improve security'. Will you mail Bolo and the editors and the map files to me instead?"
No. Shooting yourself in the foot might get you out of the army, but I'm doing a PhD in networking, so don't expect any sympathy from me if you are deliberately destroying the worldwide network that I am working to build.
• "Can I get Bolo from you by transferring it by modem?"
I don't have a modem. Never had. My apartment has an Ethernet connection direct onto the Internet, it runs 700 times faster than a 14.4Kbaud modem, I can have unlimited numbers of simultaneous connections to computers all over the world 24 hours a day, and there's no monthly phone service to pay. Probably never will get a modem.
• "How do you get an Internet connection in your apartment? Can I get one?"
No. Blame the telephone companies. I get ethernet because I live on Stanford Campus. If I move half a mile to the East, to a house off campus, then the phone company will charge me $1200 installation plus $240 per month for 1/178 of the data rate I have now. Why? Because they get rich selling 64kbit/sec audio telephone calls, and they are not going to undermine their own market by selling multi-megabit computer data links at anything less than the same dollar-per-bit price. They don't have to offer a competitive price because current Federal law makes it illegal for anyone else to compete with them. Don't expect to have reasonable data communications in you home this century, at least not in the USA.
• "What do you mean, 'at least not in the USA'?"
I can't answer a question without raising another, can I? England ran it's own incompatible network called JANet until only about a year ago, but now that it has switched to the Internet Protocols, they are becoming widely available. A friend of mine has Internet access (though not at Ethernet speed) in his apartment in Belsize Park, London. The cost? #15 (British Pounds -- about $23) for initial setup and #10 (about $15) monthly charge. ISDN is available in many places in Europe for the same price as a residential telephone line.
• "Hey, I love Bolo, but when are you going to write it for the IBM PC?"
Certainly not before the end of the next Ice Age, and maybe not then. DOS programming is too tedious. There are no standard operating system calls to do graphics, or digitized sound, or networking, or anything, so I'd have to write different code for every kind of mouse, and for every kind of sound card, and for every kind of graphics card (Monochrome, Hercules, Super Hercules, CGA, EGA, VGA, PGA, XGA, Super VGA Extended Super VGA, XGA2 etc.). I'd then have to do versions for DOS, and for Windows, and for OS/2, and for Windows NT. And still, after I'd done all that, a lot of the older PCs don't have any networking anyway -- in fact I think you can buy PC notebook computers even now that still don't have networking built in as standard. What's the point? For the Mac I've written one Bolo program, and it runs on every Mac there is, and groups of friends play it on aeroplanes on their PowerBooks. I'm happy.
• "My company wants to sell Bolo commercially. How about it?"
Commercialization would kill Bolo. We are at the dawn of an era. In ten years time computers, displays and networks will have evolved to the point where multi-user interactive virtual reality simulations will reach a quality which is unimaginable today. I hope that in retrospect Bolo will be regarded as as an ambitious first attempt at such a networked multi-user synthetic world, as useful research which taught valuable lessons. An attempt to bleed money out of it at this early stage would destroy it. Bolo will be freely distributed for the Macintosh and for Unix workstations (soon[ish]) because these platforms have ubiquitous networking. However, the big markets will always be in the Nintendo/Sega/IBM PC class machines, so if there is to be any commercialization, that is where it will be. In the near future, I think we can expect to see these class of machines evolve to the point where networking becomes a standard built-in feature. The Macintosh will make Bolo famous, and if you want to buy the source code to port it to one of these other machines, then give me a call in about a year's time, and we can talk about it.
• "Hey dude, are you going to MacHack/Apple WWDC etc.?"
I am a poor student, and I can't afford such luxuries. If you want to do me a favour, persuade Apple to invite me to WWDC next year.
• "Why is it called Bolo?"
Bolo is the Hindi word for communication. Bolo is about computers communicating on the network, and more importantly about humans communicating with each other, as they argue, negotiate, form alliances, agree stategies,. etc.
